When devices within a data processing system require a processor within the data processing system, typically the CPU, to perform a service routine, they will typically issue an interrupt request to that processor. When an interrupt request is received by the processor whilst it is executing a main process, the processor will typically temporarily interrupt the main process under execution, and instead execute the Interrupt Service Routine (ISR) specified by the interrupt request. The devices may be on the same chip as the processor, or may be off-chip. In a typical data processing system there will often be multiple devices which can issue such interrupt requests, and since the processor cannot simultaneously execute the ISRs defined by the plurality of interrupt requests, it is known to provide an interrupt controller for receiving the various interrupt requests, and prioritizing between them. Hence, interrupt requests from certain devices (for example a network interface) can be given higher priority than interrupt requests from other devices (for example a keyboard).
In a vectored interrupt controller (VIC) the controller will store a list of vector numbers for ISRs that are associated with each interrupt source, i.e. each device that can issue an interrupt request. Hence, when an interrupt request is received, the VIC can pass the exact location of the associated ISR code to the processor to enable the processor to begin execution of that ISR.
The interrupt requests that are issued by devices may take a variety of forms. In particular, depending on how the device is configured, an interrupt request may be issued as a level interrupt signal or a pulsed interrupt signal. A level interrupt signal is an interrupt signal that is held asserted until cleared by some action from the ISR, such action being for example the reading or writing of a register, or the draining of actual data waiting to be actioned by that ISR. Hence, devices that use such level interrupt signals will keep the interrupt signal asserted until they have some form of acknowledgement that the event causing that interrupt request to be issued has been handled.
A pulsed interrupt signal is an edge interrupt signal which is held for at least one clock cycle so that it can be sampled on a clock edge. An edge interrupt is an interrupt which asserts for a short period and is to be detected from its edge, i.e. its transition from a clear to a set state. Such edge detection does not need to be clock based, and is used commonly with timers and other devices where an acknowledgement is not needed. The pulsed interrupt signal is hence like an edge interrupt signal, except that it is read at a clear level and then subsequently read at a set level for at least one clock period in order to be treated as an edge. An edge can be converted to a pulse if required using a number of flops to synchronize the edge with the clock.
Hence, it can be seen that a key distinguishing factor between a level interrupt and a pulsed interrupt is whether the interrupt needs to be acknowledged (a level interrupt) or is self-acknowledging (a pulsed interrupt).
Known interrupt controllers have needed to know which type of interrupt signal will be issued by the devices, in order to ensure correct handling of the interrupt requests. Generally this is handled in two ways in prior art interrupt controllers. In accordance with one prior art technique, the particular inputs to the interrupt controller are arranged at the hardware level as either level triggered inputs or pulse triggered inputs. From the above discussion it is to be noted that a pulse triggered input will have an edge which is of relatively short duration but is longer than a clock period to enable it to be sampled. Hence, a device which issues level interrupt requests will be connected to an input of the interrupt controller that is level triggered, whilst a device that issues pulsed interrupt requests will be connected to an input of the interrupt controller that is pulse triggered. Whilst this approach enables correct handling of the interrupt requests issued by the various devices, it lacks flexibility, and requires a knowledge of the devices at the time the interrupt controller is built.
An alternative approach that has been used in prior art interrupt controllers is to provide, for each input of the interrupt controller, both hardware to handle level interrupts and hardware to handle pulsed interrupts. Configuration bits are then provided which can be set by software to identify for each input whether the device connected thereto is either a device issuing level interrupt requests or a device issuing pulsed interrupt requests. The configuration bits then control appropriate selection of the hardware provided in association with each input of the interrupt controller. Whilst such an approach provides flexibility with regards to how the interrupt controller is configured having regards to the devices connected thereto, it inherently involves a certain amount of redundancy within the interrupt controller due to the need to provide in association with each input both hardware capable of handling pulsed interrupt signals and hardware capable of handling level interrupt signals. In addition, the software needs to know what form of interrupt signal each device uses and set the configuration bits accordingly. This is not something which the software naturally knows, as the choice can be dependent on many factors.
Accordingly, it would be desirable to provide an improved technique for allowing an interrupt controller to handle both level interrupt requests and pulsed interrupt requests.